The auto-author-assign and mark-ready-when-ready workflows trigger on
pull_request, so PRs from forks get a read-only GITHUB_TOKEN and both jobs
fail (assignees API denied; contents: write denied). Switch both to
pull_request_target, which runs in the base-repo context with a read-write
token even for fork PRs.

This is safe because neither workflow checks out or executes PR-head code.
Both actions operate purely on the event payload (PR number, draft flag,
labels, head SHA) via the API, so the base-repo context evaluates no
untrusted code.

## What/Why

Auto-assign and auto-mark-ready silently fail on every external fork PR
because pull_request gives forks a read-only token; pull_request_target
restores a read-write token without executing fork code.

## Proof it works

actionlint and pre-commit pass. Verified kenyonj/mark-ready-when-ready reads
github.event.pull_request.head.sha (not github.sha) and toshimaru/auto-author-assign
acts via the assignees API, so neither depends on a PR-head checkout.

## Risk + AI role

Low. CI-only. Edits drafted with Claude Opus 4.8, reviewed by a human. The
main review concern is confirming neither workflow ever adds a PR-code
checkout in future edits, which would turn pull_request_target into a
pwn-request vector.

## Review focus

Whether pull_request_target is acceptable here versus gating the jobs to skip
on fork PRs (which would drop the feature for external contributors instead).

Signed-off-by: jmeridth <jmeridth@gmail.com>